One of the side effects of data processing applications and systems being moved to the “cloud”, and/or various other remote access/application server architectures, is that many users of the data processing applications and systems feel that they have lost control of their data and their particular implementation of the data processing applications and systems.
One specific problem feeding this perception, is that currently when an error occurs in the implementation of an application being accessed by an application user, the application user receives, at best, a notification simply stating that the error has occurred, and often the application users only indication that an error has occurred is that the application fails to function, and/or the application user's display screen locks up.
Currently, once the application user becomes aware that an error has occurred, the application user's only recourse is to either repeatedly attempt to access the application and perform the desired task, and/or continually poll the application, and/or application server, in attempt to reinitiate use of the application, or to shut down the application implementation/instance and start over. Not only is this an inefficient and frustrating process from the perspective of the application user, but it also leaves the application user with a sense that they are more or less “helpless” to resolve the problem and that nothing is being done by the application provider to address the issue. Currently, this impression is often left with the application user even in cases when the encountered error actually is being addressed behind the scenes by the application provider, but it is taking time to repair error.
Unfortunately, despite the fact that the application provider may indeed be in the process of repairing the error, the current lack of communication leaves the application user with the sense that their needs and their situation are unimportant to the application provider. Therefore, in many cases, instead of waiting for the application error to be repaired, the application user often simply leaves the application, and in many cases, provides negative reviews and/or evaluation data.
Clearly, the situation above is undesirable for both the application user and the provider of the application. What is needed is a method and system for providing an application user access to data indicating the status of the efforts to repair an error that occurs in an application implementation. In addition, what is needed, is a method and system that also informs the application user of the best next step to take to either repair or circumvent the error in the application instance, or what action to take once the error has been repaired by the application provider.